b. コミュニティのためのヒント
良いコミュニティがやっている/できていること
主体的な組織と周りの配慮により、コミュニティは活気に満ちていく
コミュニティの関心事に情熱を持ち、コミュニティを強く育てたいと願う コミュニティコーディネーター がいる。なるべくなら、積極的な現場の実践者がなる
ほとんどのチームから積極的に参加者を募っている
目に付き簡単に見つけられるため、誰でも活動しているコミュニティがわかり、参加方法を知ることができる
実践的で具体的な学習のために具体的な問題解決の目標に注目している
どのように行動し決定を下すかについて合意している
スクラムマスターがいる
スクラムマスターはコミュニティの作業と改善を助け、コミュニティのミーティングやワークショップをファシリテートする
Wiki, ディスカッショングループ, グループチャットを使っている
定期的に開催される
組織内で強く奨励されており、コミュニティに参加しコミュニティの活動に労力を割くことが実際に「期待されている」ことを誰もが知っている
コミュニティを殺す方法
コミュニティコーディネーターがいない、またはコーディネーターがケアをしていない
ただミーティングをするためだけに頻繁に集まる
フィーチャーチームに属していないメンバーばかりになっている
コミュニティを重要でないと考え、「忙しすぎて参加する暇がない」と軽視される
おすすめのコミュニティ
成功する組織に存在しているコミュニティ
ヒューマン・インターフェース（HI）
設計/アーキテクチャ
テスト
コミュニティの活動と成果
コミュニティはチームではなく、アイテムの実装もしない。
活動
教える（ e.g. フィーチャーチームに戻り、フレームワークの設計アイディアについてチームメンバーに教える）
研修やコーチングをまとめる（e.g. モダンな HI 設計のコースを作成する）
ガイドラインや標準を提案する
仕事の見極めをする（e.g. 「私達にはもっと高速のメッセージバスが必要」）
調査する
学習と共有を実践する（e.g. コミュニティメンバーがお互いに情報共有する LT 会の開催）
設計ワークショップを行う（e.g. ホワイトボードに集まり、フレームワークの設計アイデアを議論する
成果
何かを調査する必要性を見分ける
大きな調査は PBL を通すが、小さなものは直接コミュニティが調査できる
調査の結果「新しいフレームワークをつくる」など、後続の作業を発生させることもあるが、その作業はしない（チームではないため）
「全社的」なコミュニティ
「プロダクト間の一貫性のある UX 」など、全社的なコミュニティが必要になる場合がある
クロスファンクショナルな組織では、異なるプロダクトのコミュニティから集まったフィーチャーチームメンバーによる企業内コミュニティが扱う
e.g. 様々なコミュニティコーディネーターによるコミュニティ
「偽」のコミュニティ
過去、アーキテクチャやテストなどの単一機能チームとして構成されていて、マネージャーやスペシャリストの地位や権力構造などの変更を避けるために最適化されてしまうとこうなる